\documentclass{article}

%\usepackage[latin1]{inputenc}

% \usepackage[latin1]{inputenc}
 \usepackage[brazil]{babel}
%\usepackage[T1]{fontenc}		% fontes PS com acentos
\usepackage[utf8]{inputenc}
% \usepackage{amsmath}
% \usepackage{amsfonts}
% \usepackage{amssymb}  
 
\title{ A Methodology for Building \\ Service-Oriented Applications  in the presence of \\
Non-Functional Properties \\ {\it Precisions on the problem addressed and justification of the hypothesis and approach}}
\author{Plácido A. Souza Neto}
%\date{\today} 
 
\begin{document}
 
\maketitle 

The objective of this document is to provide precisions and address the questions stated about the methodology that we propose for addressing the specification, modeling and implementation of non functional requirements for service oriented applications. In order to better explain our ideas and precisions we organized the questions into 5 sections: background,  methodology and context (section \ref{sec:background}), problem statement and hypothesis (section \ref{sec:problem_hypothesis}), principle and approach (section \ref{sec:principles}), related work and comparison ( section \ref{sec:relatedWorks}), synthesis and discussion (section \ref{sec:synthesis}). In each section we enumerate the questions and then we propose a general discussion for partially or totally answering  to them. Partial responses are due to the complexity of the questions/suggestions that imply work that will be done after the exam for preparing the final version of the dissertation manuscript.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Background,  methodology, and context}
\label{sec:background}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
This section discusses about the main concepts and domains that compose the background of our work then we discuss about the methodology that we adopted for addressing our research. Finally, we describe the context in which it was done that justifies some of the choices we made for developing the methodology $\pi$-SODM that we propose. 
 
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Questions}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -


%________________________________________________________________________________________
\paragraph{\em Background}
%________________________________________________________________________________________
\begin{quotation}\sf\footnotesize
\noindent
1 - Qual a no\c c\~ao de ``confiabilidade'' usada no trabalho? Apesar de constar
no t\'itulo (``A methodology for building reliable service-based applications'') e
em v\'arias partes do documento, a metodologia proposta e os meta-modelos n\~ao
apresentam nenhuma caracter\'istica que sugira o desenvolvimento de aplica\c
c\~oes deste tipo. Na pr\'atica, a proposta da tese aparenta ter sido concebida
para o desenvolvimento de aplica\c c\~oes orientadas a servi\c cos em geral.      
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
3 - Al\'em da necessidade de remo\c c\~ao do termo ``reliable'' no t\'itulo,
sugiro que o t\'itulo da tese tamb\'em deveria considerar o fato de que
aplica\c c\~oes que tem servi\c cos como elementos de primeira classe s\~ao
referidas na literatura como ``service-oriented applications'' e n\~ao
``service-based applications''. N\~ao sei se houve uma discuss\~ao sobre isto,
mas esta diferen\c ca \'e significativa.
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
4 - \'E preciso explicar no texto o que \'e uma aplica\c c\~ao orientada a
servi\c co confi\'avel, ou seja, qual a no\c c\~ao de ``confiabilidade''
adotada. Observe que ``confiabilidade'' tamb\'em \'e um RNF. Caracterizar bem a
confiabilidade destas aplica\c c\~oes ajudaria a entender como a metodologia
trata as particularidades deste requisito n\~ao funcional. Neste ponto, vale a
pergunta: e se as aplica\c c\~oes precisassem ser ``seguras'' (outro requisito
n\~ao funcional), a metodologia poderia ser tamb\'em aplicada?      
\end{quotation}

%\begin{quotation}\sf\footnotesize
%\noindent
%9 - Verificar a frase ``\ldots some proposals extend WSDL adding behavioral
%characteristics, such as PEWS[27], BPEL4WS\ldots'' Observe que BPEL4WS n\~ao \'e uma
%extens\~ao de WSDL. WSDL \'e uma nota\c c\~ao para defini\c c\~ao de interface de servi\c cos e
%WS-BPEL \'e uma notao para composi\c cao de servi\c cos, ou seja, s\~ao nota\c c\~oes
%com prop\'ositos muito distintos. Considere reescrever esta frase.    
%\end{quotation} 

\begin{quotation}\sf\footnotesize
\noindent
12 - Rever ou explicar a frase a seguir: ``The design addresses the functional
requirements while architecture provides the non-functional requirements like
scalability, reliability and performance are realized.'' Esta frase sugere que o
projeto (design) trata os requsitos funcionais enquanto a arquitetura trata os
RNFs. Na pr\'atica, no entanto uma diferen\c ca b\'asica destes requisitos n\~ao \'e a etapa de desenvolvimento em que eles s\~ao tratados, mas o fato de que normalmente
os requisitos funcionais est\~ao confinados (ou s\~ao implementados) em elementos
pontuais da implementa\c c\~ao. Por sua vez, os RNFs s\~ao pervasivos, ou seja, est\~ao
normalmente espalhados em toda a implementa\c c\~ao. Por exemplo, para ser seguro,
todas as partes do sistema precisam ser seguras.       
\end{quotation}

%________________________________________________________________________________________
\paragraph{\em Context}
%________________________________________________________________________________________

 \begin{quotation}\sf\footnotesize
\noindent
10 - Na frase a seguir n\~ao fica claro como MDA alinha os conceitos de RNFs e
SOC: ``MDA [67] is an important approach for the alignment between highlevel
information modelling, non-functional requirements\ldots''. Na pr\'atica, \'e
preciso explicar porque o uso de MDA favorece/ajuda o tratamento de RNFs.
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
20 - Esclarecer o que s\~ao Business Services. Este termo n\~ao \'e comum na \'area de servi\c cos. 
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
22 - N\~ao tenho certeza, mas acredito que alguns elementos dos metamodelos da
$\pi$SOD-M j\'a tenham sido definidos na SOD-M. Seria interessante, se isto est\'a
acontecendo, destacar estes elementos para deixar claro ao leitor os elementos
que s\~ao exclusivos da $\pi$SOD-M.    
\end{quotation}
 

\begin{quotation}\sf\footnotesize
\noindent
23 - Observando a Figura 4, \'e poss\'ivel observar que $\pi$SOD-M tem as mesmas
etapas de SOD-M, mas com foco no RNFs. Isto sugere (posso estar enganado) que toda a
parte ``funcional'' foi aproveitada na SOD-M. Isto \'e verdade?   
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
30 - N\~ao est\'a muito clara (justificada) a necessidade de um ``Process Model'' e
um ``Composition Model''. Observe que em nota\c c\~oes como WS-BPEL os elementos destes
dois modelos est\~ao de certa forma juntos, ou seja, talvez seja interessante
justificar porque a metodologia adota esta separa\c c\~ao.    
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
35 - Quem \'e o ``Application designer''? Qual o perfil? \'e algu\'em de neg\'ocio ou de
TI? Isto \'e importante estar definido na metodologia, pois provavelmente existem
v\'arios atores (business expert, qos expert, TI expert) envolvidos nas v\'arias
etapas da metodologia. Por exemplo, algu\'em de neg\'ocio seria capaz de definir uma
express\~ao como estas apresentadas na Figura 20 (e.g., $\#$bankBlance $>$
paymentValue \&\& \ldots ). Veja ainda na p\'agina 85: quem \'e o
``designer'' referido na frase ``The designer must specify\ldots''.      
\end{quotation}

%________________________________________________________________________________________
\paragraph{\em Methodology: systematic review}
%________________________________________________________________________________________
\begin{quotation}\sf\footnotesize
\noindent
15 - Acredito que as Research Questions poderiam ser melhor formuladas. Por
exemplo, em rela\c c\~ao RQ1 (``How are NFRs modelled by existing methodologies for
developing reliable Web services''), as nota\c c\~oes para expressar RNFs quase
nunca est\~ao associadas a metodologias de desenvolvimento de software (muito menos a
metodologias -ainda muito escassas - de desenvolvimento orientado a servi\c
co). A maioria das nota\c c\~oes para expressar RNFs s\~ao definidas
isoladamente, pois o tratamento explícito de RNFs ainda \'e muito raro. Acredito que por conta disto
voc\^e n\~ao encontrou i-star, GRL, NFR e KAOS, pois exceto NFR, os outros n\~ao
est\~ao integrados a nenhuma metodologia de desenvolvimento de software.         
\end{quotation}


 
\begin{quotation}\sf\footnotesize
\noindent
16 - N\~ao entendi a RQ4 e nem as poss\'iveis respostas a RQ6  
\end{quotation}
\begin{quotation}\sf\footnotesize
\noindent
21 - Uma das RQs poderia ser ``metodologias fazem o desenvolvimento de
composi\c c\~oes por orquestra\c c\~ao ou por coreografia?'' Isto mereceria tamb\'em uma
discuss\~ao na tese, pois s\~ao as estrat\'egias normalmente usadas na computa\c c\~ao
orientada a servi\c cos. Ainda relacionado a isto, outro ponto que deveria ter sido
discutido na tese \'e o fato de que metodologias para este tipo de desenvolvimento
tem como etapas principais a ``sele\c c\~ao'' e a ``combina\c c\~ao'' de servi\c cos. Compare
estas etapas com as etapas tradicionais.       
\end{quotation}

 
\begin{quotation}\sf\footnotesize
\noindent
17 - Observando os strings utilizados para a busca nas bases bibliogr\'aficas, \'e
poss\'ivel observar que: no mundo de servi\c cos, o termo QoS \'e muito mais
comum do que ``non-functional requirements'' e s\~ao usados como sin\^onimos na \'area. Isto
pode ter tido um impacto muito grande nos resultados retornados.   
\end{quotation}


% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Background: Non functional properties and service oriented applications}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
The background of our work consists of the works addressing non-functional requirements in three domains: distributed systems, databases and software engineering. The approaches, models and solutions proposed in these domains were studied, integrated and adapted for addressing the construction of service oriented applications in the presence of non functional requirements. We underline in the following the key concepts that we used from each of the domains of the background of our work.

Expressing and enforcing non functional properties for distributed systems is a well-known problem with  several associated existing solutions that have modeled thoroughly  them for providing middleware services. For example in object oriented solutions  like CORBA, and component oriented solutions like EJB. Models and protocols have been defined in the distributed systems and the database domains for dealing with non-functional requirements that concern for example, security , failure tolerance (e.g, transaction monitors, synchronization protocols like 2PC), persistence. Lately service oriented applications, call for approaches that can include these aspects trying to be loyal to the facility of construction philosophy. Some solutions leave this task to the middleware infrastructure (e.g., the service bus petals \footnote{http://petals.ow2.org} offers some non-functional services), to the engines that execute them. Other approaches like \cite{wij}  include the code that implements non-functional properties, as protocols within the coordination code  that implements the application logic of service oriented applications or within the communication protocol used for calling services methods (e.g. data encryption of SOAP messages). This later approach is particular to works stemming from the Business Process domain (BPM  \cite{bpmn}) and also to WS-* standards. 


In our work, not respecting a non functional property expressed in a specification in the design phase,  implies an exceptional behavior of the application. These exceptions are dealt according to predefined actions also expressed in the design phase, oriented to tolerate these exceptions. In consequence, in our work, a reliable service coordination is the one that conforms to a specification and that is exception tolerant, where exceptions concern the violation of  constraints and business rules defined in the specification.  Different to existing works, our approach supposes autonomous services \footnote{A service is autonomous when it does not share its execution state, it can evolve independently of the application that use them, and it does not provide means for controlling its availability.} and does not associate these properties to services but to an application logic implemented as a coordination. Of course, when non-functional properties associated to a service coordination depend on the properties of participating services, the programmer should be aware of that and provide non-functional properties partially, model compensating strategies for ensuring them or at least program recovery actions that can signal an exception when a non-functional property is violated.

We used the notion of reliability in order to have a common approach for dealing with non-functional requirements (i.e., ensuring that the system respects them and defining actions when they are not respected). The concept of reliability of service-oriented applications  used in our work is associated to the concepts of {\it correctness}, {\it robustness} and {\it reliability} introduced in  (i) \textit{Design by
Contract} \cite{Meyer92,MeyerN93,Meyer97}, (ii) referred by \cite{Meyer92,Meyer97} and (iii) defined in the database domain. 

\begin{enumerate}
\item 
\textit{Design by
Contract} defines reliability as a concern that integrates the ability of a software element to perform the tasks as defined in its specification (correctness) and that reacts appropriately to abnormal conditions (robustness). Furthermore,  the notion of contract proposed by \cite{Meyer92,MeyerN93,Meyer97} enables the specification of actions to take when one of these properties is not respected by a service. 

%\begin{itemize}
 % \item Correctness: The ability of software products to perform their exact tasks, 
%as defined by their specification;
  % \item Robustness: The ability of software systems to react appropriately to 
   %abnormal conditions.
  % \item Reliability: A concern encompassing correctness and robustness. As the
  % contracts for service interfaces are designed to ensure the expected result
   %after the task performed by the service, and that if the contract is broken,
   %the service does not apply to the application, we try to ensure the
   %correctness by applying contracts in independent services.
%\end{itemize}

%Concerning robustness, when a contract is broken, the specification 
%describes alternative paths for the user does not notice the error. 

%Thus, we can say that the use of design by contract for services in service-oriented
%applications can ensure the reliability of these kind of applications.     

\item \cite{Meyer92,Meyer97} associates the notion of reliability to the conformance between the requirements specification of a software component and its implementation with the objectives to avoid possible bugs. Thus, reliability is associated to the absence of bugs of a software component with respect to its specification (during the design phase).   
 
 \item Finally, in the database domain, reliability is often related to a kind
 of failure tolerance in the sense that a database application is reliable if it
 handles exception and it ensures that data consistency will be maintained despite possible physical and logic failures \cite{AdibaA81,MartinAD92}.

\end{enumerate} 
In this context, the scientific challenge was to analyze approaches concerning the non-functional properties and generalize them into the meta-models that are core components of our methodology.

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Methodology: systematic review}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
As part of our research methodology we started  performing a systematic review
\cite{AgarwalLS09,Babamir2010,CeriDMF07,PortillaHE08,Espinosa-Oviedo2011a,Milanovic2006,Espinosa-OviedoVZC09,BianculliGSBG07}
in order to  track existing works dealing with non-functional requirements and with methodologies for building service oriented applications. {\em Since non-functional requirements have been addressed in different domains the objective was to establish an homogeneous vocabulary and taxonomy used for defining them and also identifying how they are added to systems and particularly to service oriented applications}.  Following this method we defined a set of research questions presented in Chapter 2 of the manuscript.

Since the objective of our work was to develop a methodology for supporting the service oriented application development process,  the  goal of RQ$_4$ was to look for a `` standard'' or a classification of non functional requirements  for service-oriented development. As any research question, it can be too particular and can leave some works outside its scope (e.g., KAOS \cite{UszokBJ04} and i-star \cite{Yu97} were not part of the result). We do not deny the research done in software engineering about non-functional requirements, we believe that their results can be helpful for completing our meta-models  (if we find cases where our meta-models seem limited), since our proposal is flexible enough. Anyway, we will complete our state of the art with this works and we will compare our work with them. 

Similarly, the objective of  RQ$_6$ was to find works addressing non functional requirements of service compositions. We believe that the characteristics of services, in particular, their autonomy and the philosophy of simplicity of construction of service oriented applications add new challenges to the modeling and implementation of associated non-functional requirements. We did not want to exclude the vast work done on non-functional requirements, in the distributed systems, database and, software engineering domains but we wanted to identify in which extent our objectives were addressed by other projects directly addressing service oriented applications.
 
 

Finally, a change in the search query to consider QoS, would be:
\textit{[Non-Functional requirements or Non-Functional properties or Non-Functional
attributes or QoS] And [Service-oriented application or Web
Service-based applications or Service Composition development]}


Based on the proposed query, we defined some variations to verify what is the best to consider.  The 5 queries were evaluated on  IEEE, ACM and Science Direct
libraries:

\begin{itemize}
\item \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
``Non-Functional attributes" OR ``QoS") AND (``Service-Oriented")}

\item \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
``Non-Functional attributes" OR ``QoS") AND (``Service-Based")} 

  \item \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
``Non-Functional attributes" OR ``QoS") AND (``Service Composition")} 

  \item \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
``Non-Functional attributes" OR ``QoS") AND (``Service-Based" OR
``Service-Ori\-ented")} 

\item  \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
``Non-Functional attributes" OR ``QoS") AND (``Service-Based" OR
``Service-Ori\-ented" OR ``Service Composition")} 
\end{itemize}

Figure \ref{tab:result01} summarizes the results: (i) the total results for each query performed,
(ii) the new works considering the related works presented in the thesis, and
(iii) the percentage of these new works.



\begin{table}
\centering 
\begin{tabular}{l|c|c|c|c}
  \hline
  \hline
   & IEEE  & ACM  & Science Direct & Total \\
  \hline
  \hline
  Total results - query 1 & 50 & 10  & 54  & 114  \\
  New works  & 48  & 9  & 51 & 108 \\
  New works (\%) & 96\% & 90\%  & 94\%  & 94.7\%  \\ 
  \hline
  Total results - query 2 & 9  & 4 & 32  & 47  \\
  New works  & 9 & 4 & 32 & 45 \\
  New works (\%) & 100\%  & 100\%  & 100\%  & 95.7\%  \\ 
  \hline
  Total results - query 3 & 25 & 8 & 42 & 75  \\
  New works  & 24 & 7 & 40 & 71  \\
  New works (\%) & 96\%  & 87\%   & 95\% & 94.6\% \\  
  \hline
  Total results - query 4 & 4 & 1 & 80 & 85 \\
  New works  & 4 & 1 & 77 & 82  \\
  New works (\%) & 100\% &  100\% & 96\%   & 96\%  \\ 
  \hline
  Total results - query 5 & 1 & 1 & 80 & 82  \\
  New works  & 1 & 1 & 77 & 79 \\
  New works (\%) & 100\%  & 100\%  & 96\% & 96\% \\ 
  \hline
  \hline
\end{tabular}
\caption{Summary of the works selected considering different queries.}
\label{tab:result01}
\end{table} 

%It is important to note that we only perform the queries to verify the total of
%results, unlike the process of systematic review presented in the thesis (table
%\ref{tab:result02}). The final result of the systematic review (step 2, table
%\ref{tab:result02}), were considered 10.76\% (IEEE), 4\% (ACM) 5.42\% (Science Direct) of the total of works returned in the query performed in the
%thesis. The query was: \textsc{\textit{(((``non functional properties'') OR (``non
%functional requirements'')) AND ``web service'' AND ``composition''))}}


\begin{table}
\begin{tabular}{l|c|c|c}
  \hline
  \hline
   & IEEE Explorer & ACM Library & Science Direct \\
  \hline
  \hline
  Total results & 65 & 271 & 166\\ 
  \hline
  Step one - results selected & 19 & 10 & 20  \\
  Step one - results selected (\%) & 29.23\% & 13.33\% & 12\% \\ 
  \hline 
  Step two - results selected & 7 & 3 & 9 \\
  Step two - results selected (\%)  & 10.76\% & 4\% & 5.42\%\\ 
  \hline
  \hline
\end{tabular}
\caption{Summary of the systematic review in the thesis' manuscript.}
\label{tab:result02}
\end{table} 

% \subsubsection{IEEE Explorer}
% 
% 
% \subsubsection{ACM Explorer}
% 
% Based on the proposed query, in the ACM Explorer we have the following results
% (*using variations of the proposed query*):
% 
% \begin{itemize}
% \item \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
% ``Non-Functional attributes" OR ``QoS") AND (``Service-Oriented")} with \textbf{10}
% papers returned as result.
% 
% \item \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
% ``Non-Functional attributes" OR ``QoS") AND (``Service-Based")} with \textbf{4}
% papers returned as result.
%  
%   \item \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
% ``Non-Functional attributes" OR ``QoS") AND (``Service Composition")} with
% \textbf{8} papers returned as result.
% 
%   \item \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
% ``Non-Functional attributes" OR ``QoS") AND (``Service-Based" OR
% ``Service-Ori\-ented")} with \textbf{1} papers returned as result.
% 
% \item  \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
% ``Non-Functional attributes" OR ``QoS") AND (``Service-Based" OR
% ``Service-Ori\-ented" OR ``Service Composition")} with \textbf{1} paper returned
% as result.
% \end{itemize}
% 
% \subsubsection{Science Direct Explorer}
% 
% Based on the proposed query, in the Science Direct Explorer we have the following results
% (*using variations of the proposed query*):
% 
% \begin{itemize}
% \item \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
% ``Non-Functional attributes" OR ``QoS") AND (``Service-Oriented")} with \textbf{54}
% papers returned as result.
% 
% \item \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
% ``Non-Functional attributes" OR ``QoS") AND (``Service-Based")} with \textbf{32}
% papers returned as result.
% 
%   \item \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
% ``Non-Functional attributes" OR ``QoS") AND (``Service Composition")} with
% \textbf{42} papers returned as result.
% 
%   \item \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
% ``Non-Functional attributes" OR ``QoS") AND (``Service-Based" OR 
% ``Service-Ori\-ented")} with \textbf{80} papers returned as result.
% 
% \item  \textit{(``Non-Functional requirements" OR ``Non-Functional Properties" OR
% ``Non-Functional attributes" OR ``QoS") AND (``Service-Based" OR
% ``Service-Ori\-ented" OR ``Service Composition development")} with \textbf{80}
% papers returned as result.
% \end{itemize}

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Context: Building service oriented applications using software engineering methodologies}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

Our work extends the existing methodology SOD-M that provides meta-models for modeling and implementing services oriented applications. The objective of the methodology to support the construction of such kind of applications and ensure their conformance to its specification as stated by user requirements during the analysis phase. Providing a conceptual framework \footnote{We refer here to the definition of  framework as {\em a structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed,   a set of assumptions, concepts, values, and practices that constitutes a way of viewing reality}.}  based on meta-models for modeling a service oriented application ensures that the resulting implementation will conform to user requirements. On the other hand, thanks to transformations among models, the programmer can rely on a partial automatic generation of the models of the application. This reduces the programming effort and provides  an abstract vision of the application that can be important for following the construction process. Particularly, in the case of SOD-M a service oriented application logic is modeled as a business process that can be implemented by a composing existing artifacts called  (business) services \footnote{Note that the term business services is used to make the difference between the services that participate in the implementation of an application logic from the services used for implementing non functional aspects. For instance, CORBA domain services are those equivalent to  business services. BPMN \cite{bpmn} defines a similar
term called \textit{Service operation}  that
is part of the business process.}. In SOD-M, a business service is represented by a service
(or a service composition) that will implement a task within a  business process. 


From our point of view, non-functional properties are in general not considered when a service oriented application is modeled. Methodologies in general focus on the application logic  and then rely on  programmers for implementing non-functional properties either by coding them directly (e.g., handling exceptions) or by configuring the services provided by the middleware (e.g., persistence or transactional properties). 



 The challenge to the use of MDD in modeling of cross-cutting aspects of the
application from the more abstract level of design is the ability to use
different types of models for different purposes and understand the differences
between the terminologies for the non-functional properties
\cite{LimingZhu2009}.




%In $\pi$SOD-M the concept of \textit{Business service} represents services
%that are part of a business process. 

%$\pi$SOD-M considers these concepts to cover the non-funcional aspects and
%service-oriented standards for a MDA based development. $\pi$SOD-M inherits all
%the functional part from SOD-M, and includes the elements necessary to model
%non-functional aspecs in terms of \textsc{Policy}.



%MDD is an important approach for aligning information about abstract modeling
%levels and non-functional requirements. In model-based development, the
%information will be refined at each level through model transformation,
%thereby the NFRs can be best described their concepts and needs in the
%application development.

%MDD has beed increasingly employed to guide development with focus on the
%generation of code from models. The modeling aspects of non-functional
%properties remains difficult. Models that describe non-functional properties may be used
%to express, in the specification phase, transversal characteristics of the
%application.  As the specification of these models is done , essential
%properties are being incremented \cite{Rottger04}.





   
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Problem Statement and Hypothesis}
\label{sec:problem_hypothesis}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Questions}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

\begin{quotation}\sf\footnotesize
\noindent
2 - Senti falta de justificativas de porque a proposta foi desenvolvida apenas
para Web services. Observe que existem diversos servi\c cos que n\~ao s\~ao Web,
ou seja, n\~ao s\~ao descritos em WSDL, n\~ao s\~ao armazenados em UDDIs e usam outros
protocolos de comunica\c c\~ao diferentes de SOAP.   
\end{quotation} 

\begin{quotation}\sf\footnotesize
\noindent
8 - Por que Web services e n\~ao Servi\c cos foram considerados? Por que o trabalho
considera apenas Web services? Existe uma raz\~ao particular para isto, uma vez
que torna a solu\c c\~ao restrita ao universo de Web Services?  
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
7 - N\~ao h\'a uma discuss\~ao de porque tratar RNF \'e dif\'icil ou porque SOC
facilita o tratamento destes requisitos.
\end{quotation}
 
\begin{quotation}\sf\footnotesize
\noindent
36 - Que linguagens s\~ao estas ``behavioural web service interface languages''?    
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
18 - Senti falta tamb\'em de uma discuss\~ao sobre ``correla\c c\~ao'', ``conflitos'' e
``prioridade'' entre RNFs. Estes dois aspectos s\~ao muito discutidos quando
fala-se em RNFs.   
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
27 - Senti falta de uma descri\c c\~ao precisa do que sejam NF-Attributes,
NF-Properties e NF-Requirements. 
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
28 - N\~ao entendi a frase ``The quality properties at the system level represent
a behaviour that is part of the workflow.''
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
32 - N\~ao h\'a uma explica\c c\~ao sobre (i) porque a metodologia foi estruturada em
tr\^es vis\~oes (Business, System and Policy) e (ii) como chegou-se a estas tr\^es
vis\~oes.  
\end{quotation} 


\begin{quotation}\sf\footnotesize
\noindent
39 - J\'a existia um metamodelo de PEWS?   
\end{quotation} 


% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Problem: Modeling non functional properties of service oriented applications} 
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

Even with the growing interest in developing higher-level models and design
paradigms, current technology seems limited for
expressing constraints as  non-functional requirements (NFRs)
and associating them  to service oriented applications \cite{Chung91,MylopoulosBook99}. NFRs
specify global constraints that must be satisfied by the software \cite{RosaC04}. 
%However, this
%kind of requirements are not implemented such as functional requirements. 

Ensuring non-functional properties has been challenging when developing applications because they are both related to the business rules of the application (e.g., defined user rights associated to the execution of applications' functions: only the manager can authorize the modification of a salary.) but also to the technical characteristics of the infrastructure where the application is executed (e.g., the messages transmitted through the network cannot be modified while transmitted). Having a methodology for specifying the application logic and its associated non-functional properties starting in the early phases of the development process is a difficult problem because:
\begin{itemize}
  \item the designer must make the difference between requirements that concern the application logic and the non functional requirements; 
  \item the  non functional requirements specified in an abstract  way (e.g., as business rules) must provide enough information to be translated into the specification of technical aspects implementing a concrete non-functional property. For example, saying that the payment, the authorization of delivering a package and the modification of the stock must be all together successful otherwise they must be undone, can be translated into an atomicity property associated to these operations (i.e., either the three of them are executed or none of them);
  \item  the methodology must provide general enough concepts  for modeling quite different non-functional requirements and strategies to ensure that their abstract specification will lead to the implementation of protocols that will ensure these properties while the application is executed. 
\end{itemize}

In the case of service oriented applications it is particularly difficult to add non-functional properties because in general the existing protocols and models implementing some of them assume that
\begin{itemize}
\item it is possible to have a global control of  the artifacts implementing the application or 
\item at least they export interfaces in order to have information about their execution state, the messages exchanged with others, the conditions in which messages are transmitted on the network.
\end{itemize} 
In the case of service oriented applications, the services used as construction units are autonomous, they do not share information about the state and data they manage and there are few engagements with respect to their availability and evolution. This aspect calls for flexible protocols and models that can accept a best effort approach for ensuring non-functional properties.  For example, to provide security, all services of the composition should be safe; to ensure satisfactory
response time, all services of the composition must provide the results obeying
restrictions of the client.  These assumptions cannot be made, and thus in some cases non-functional properties cannot be completely ensured. The methodology should take into consideration this situation in order to reflect it along the different construction phases.  

 

%However, as services are
%independent components and has a finer granularity, to ensure that services
%constraints are satisfied is a bit easier. As each service provides access to
%its interface, its clients have an opportunity to check if the result satisfies
%or not, even during the execution of the application. Moreover, the guarantee of
%non-functional properties in service composition is not as trivial to solve.
%This occurs because of non-functional requirements, in most cases, have
%distributive characteristics, or even opposite. For example, to provide
%security, all services of the composition should be safe. To ensure satisfactory
%response time, all services of the composition must provide the results obeying
%restrictions of the client.  

%Due to these problems, non-functional properties are treated in services
%in a particular way, for example, most studies attempt to ensure
%specific requirements in the modeling of service-oriented applications.
%Knowing this problem, we try to cover with $\pi$SOD-M a slightly
%more general and abstract approach based on contracts for services. Contracts
%for services can be specified for both services simple or compound.



%_________________________________________________________________________________________
\paragraph{Hypothesis}
%_________________________________________________________________________________________

\begin{enumerate}
\item Business rules and constraints specified as application requirements can be translated into non-functional properties that can be associated to a service composition that implements the application logic of a service oriented application.

\item We believe that it is possible to model non-functional properties during the early stages of applications development process and that this can be done using an MDD approach. Therefore, we assume that, at least in the context of service oriented applications, it is possible to propose meta-models that can be specialized for expressing non-functional properties and that can be associated to concepts used for modeling the application logic. 

\item We use the notion of service in a general way without necessarily associating it to the Web. A service is a software element implemented by a service provider that exports an interface for calling the service and that is accessible through a network.

\item It is possible to provide a methodology for building service oriented applications that is agnostic of the data models exchanged by the services, the interface definition language used for describing the services interfaces, the protocols and architectures used for calling services,   the composition languages and the execution engines. This implies that our methodology can consider REST and SOAP services with interfaces described in WSDL, semistructured (JSON, XML), unstructured and structured data models, and compositions expressed in any language. 

%Likewise, the proposed methodology ($\pi$SOD-M) can be applied to any service
%approach, not necessarily Web services. $\pi$-PEWS specifications
%can have different types of namespaces, not only WSDL. It is possible to use the
%methodology even if the used approaches are JSON, REST, Java RMI, WCF, and so
%on. As contracts are about functions, the restrictions described  through the
%contracts can used for any approach, not only Web services.






\end{enumerate}
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Principle and Approach}
\label{sec:principles}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Questions}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
%____________________________________________________________________________________________
\paragraph{{\em Principle and approach}}
%____________________________________________________________________________________________

\begin{quotation}\sf\footnotesize
\noindent
11 - Observe na frase a seguir que WSDL e WS-BPEL n\~ao s\~ao ``plataformas de
servi\c co'': ``MDA allows the specification of a system as an abstract model,
which may be realized as a concrete implementation (program) for a particular service
platform (e.g. WSDL, BPEL or PEWS).''    
\end{quotation}

\begin{quotation}\sf\footnotesize 
\noindent
13 - Sugiro que tamb\'em seja discutido na tese o seguinte ponto: associar RNFs a
``composi\c c\~oes de servi\c cos'' ou a ``servi\c cos'' pode ser muito
dif\'icil, pois alguns RNFs s\~ao ``distributivos''. Imagine que o
desenvolvedor define que a composi\c c\~ao (e.g., formada por 5 servi\c cos) \'e segura. Isto implica (mesmo que n\~ao seja dito
pelo desenvolvedor) que todos os servi\c cos precisam ser seguros e que todas as
comunica\c c\~oes entre ele s\~ao seguras. Mas, imagine que um dos servi\c cos
n\~ao \'e seguro. Como esta situa\c c\~ao \'e tratada pela metodologia? Quais os artefatos
gerados no final?      
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
24 - DEVISE \'e uma metodologia?  
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
25 - N\~ao \'e muito claro como um ``requisito n\~ao-funcional'' pode ser representado
por um ``use case''.
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
26 - Talvez esteja claro no texto, mas n\~ao ficou claro para mim os mapeamentos
``Constraint'' -> Contract e Contract-> Policy s\~ao realizados.
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
29 - Observar esta parte ``$\pi$SOD-M is a MDA (Model Driven Architecture) based
methodology. It provides a framework for building service compositions
considering their non-functional requirements.'' A metodologia fornece um
framework? Os conceitos de metodologia e framework s\~ao muito distintos.   
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
31 - Senti falta de uma descri\c c\~ao passo-a-passo da Figura 5, por exemplo,
``Inicialmente tem-se uma especifica\c c\~ao de um processo de neg\'ocio que \'e
transformado em um UseCase model...'' Esta explica\c c\~ao at\'e existe, mas est\'a
dilu\'ida nas p\'aginas subsequentes do texto quando voc\^e diz ``After modelling the
system services and feature...'' (pp. 62). Como esta figura \'e muito importante,
ela deveria ser bem descrita.      
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
33 - Sugiro uma explica\c c\~ao sobre o mapeamento apresentado na Figura 16. Por
exemplo, \'e preciso justificar porque uma ``Business Service'' \'e representado em
UML por um ester\'otipo.  
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
37 - Seria interessante justificar porque a linguagem PEWS foi escolhida para a
implementa\c c\~ao. Isto remete a outro importante, a metodologia \'e desacoplada desta
linguagem, ou seja, ela suportaria a gera\c c\~ao de composi\c c\~oes execut\'aveis em
WS-BPEL?   
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
41 - Senti falta dos requisitos do ambiente de desenvolvimento proposto. Veja
que a Figura 41 j\'a mostra a arquitetura. Quais os requisitos que geraram esta arquitetura?
\end{quotation}

\begin{quotation}\sf\footnotesize  
\noindent
42 - O ambiente n\~ao deveria ser estruturado em ``vis\~oes'' como a metodologia?
\end{quotation}


%____________________________________________________________________________________________
\paragraph{{\em Evaluation}}
%____________________________________________________________________________________________
\begin{quotation}\sf\footnotesize
\noindent
5 - Deveria haver uma discuss\~ao na tese sobre a consist\^encia dos modelos.     
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
6 - Por que n\~ao foi feita nenhuma valida\c c\~ao ``quantitativa'' para mostrar quanto
a metodologia proposta ``facilita o desenvolvimento de aplica\c c\~oes
orientadas a servi\c co'' (ver defini\c c\~ao de valida\c c\~ao na pp. 116)? N\~ao h\'a evid\^encias de que a
metodologia facilita o desenvolvimento de aplica\c c\~oes orientadas a servi\c co.
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
43 - Ao inv\'es de ``estudos de caso'' colocaria ``Examples''. Removeria o Estudo
de Caso 1, pois ele foi usado em toda a tese e todos os principais elementos j\'a
foram apresentados no Cap\'itulo 3 (inclusive as figuras s\~ao as mesmas). 
\end{quotation}

 
\begin{quotation}\sf\footnotesize
\noindent
44 - N\~ao fica claro o que \'e a ``an\'alise qualitativa'' mencionada.
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
45 - Explicar melhor os trabalhos futuros. Evite itemiz\'a-los.
\end{quotation}
  

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Principle}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

%We consider that one of the most important process when designing a system is
%the requirement analysis process, especially identifying the non-functional requirements and the system
%restrictions. In order to ease the coding process and let the developer focus on
%technical issues, the system may be automatically generated, from
%the system design. 
 
$\pi$-SOD-M supports the construction of service oriented applications that implement business processes.
Therefore, it proposes a development process based on the definition of models (instances of the meta-modes) and transformations (presented in the Figure 5 of the thesis) for semi-automatically generating different levels of abstraction that describe a service oriented application from abstract platform independent views (CIM and PIM level) to platform dependent views and the PSM and implementation levels. 
 We extended the Business and Service views of the SOD-M method \cite{CastroMV11}. The
Business view defines  the concepts for modeling a business process, while the
Service view defines the concepts  for designing services compositions. Our methodology introduces  concepts (e.g. NF-requirement, constraint, assertion, contract, policy)  for describing constraints associated to services and non-functional properties associated to service processes (presented in  Figure 6 of the thesis) . 

The organization into different levels of abstraction of non-functional properties proposed by $\pi$-SOD-M relies on its concept of Non functional Requirement (NFR) defined  as a group of semantically correlated non-functional
attributes (NFA). For example, \textit{security} is an NFR that
comprises attributes such as \textit{confidentiality} and \textit{integrity}.
NFR are used for modeling global constraints, NFAs model non-fuctional characteristics that can be precisely measured, such as
 \textit{performance} \cite{RosaC04}. This kind of characteristics are closer to
 implementation. Then, the concept  non-functional property proposed by
 \cite{RosaC04,Chung2009,MylopoulosBook99}  is used for modeling  different
 types of software constraints. Thus, it  generalizes the concepts NFR and NFA of  our methodology. In $\pi$SOD-M, NFR and NFA are  modelled along the different modeling levels  as \textsc{constraint types} that can be grouped and  transformed into \textsc{contract types}, that can be transformed into
 \textsc{policy types}. A constraint type is used for representing  a non-functional
 property.

The  objective and contribution of our work is to
provide a conceptual structure (called framework)  and associated environment to: 
\begin{itemize}
\item Capture the system requirements and
specification using high-level abstraction models (represented as computation
independent models, CIMs). The objective is to provide concepts for supporting the specification and representation of a business process including its application logic and business rules. 
\item  Semi-automatize the generation of the  Platform Independent Models (PIMs)
from the specification given by the CIMs. The 
PIMs specify the business process as  a service process and its associated business rules  and  constraints as policies.  A policy expresses actions to do (recovery) if business rules and constraints are not respected.
\item Transform such models into platform specific models (PSMs).  The PSMs in $\pi$-SOD-M meta-model the $\pi$-PEWs language \cite{Placido2010LTPD} that will serve as intermediate language for generating executable code in the final phase of the methodology  process. The reason is that $\pi$-SOD-M was developed in the context of a project where it is used for declaratively implementing service compositions. We
defined the $\pi$-PEWS meta-model, based on the $\pi$-PEWS syntaxis, and then the
mapping rules between PIM and PSM.
\item Serialize  PSMs into the executable-code that implements the system. 
\end{itemize}  

%As our approach is based on contracts for services, the guarantee of
 %on-functional properties is directly related to the verification 
 %of contracts, inputs and outputs required for a service, or a
%composition of services. We propose guidelines for building service compositions that include
 %non-functional properties. These aspects are implemented as \textsc{policies}
 %for the application services. The design of this aspects integrates both
 %functional and non-functional requirements, and the treatment we give to
 %compound services are that if there is a conflict in relation to contracts, the contract
 %is broken and the composition is not suitable for the application. The Policy
 %view concepts (presented in the Figure 6 of the thesis) are used to model the
 %non-functional properties for service-oriented applications in $\pi$-SOD-M.
%
%The modeling of business process proposed in $\pi$SOD-M is simpler than
%those seen in the WS-BPEL. In addition we use two models to express: (i) the
%main workflow, and (ii) the relationship of each activity with external services.

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection {Approach}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

The models proposed by $\pi$SOD-M represent  a service oriented application in presence of non-functional properties as well as the constraints associated
to services.
The $\pi$SOD-M  supposes that the programmer uses  requirements and business specification documents \cite{scube2010book} in order to define a 
$\pi$-UseCase model by instantiating the concepts of the $\pi$-UseCase meta-model. This meta-model extends the UML use-case meta-model with concepts for representing requirements and constraints that will be used for specifying a services oriented application. The
$\pi$-UseCase model represents the use cases, requirements and
constraints of the service oriented application. Based on this model, a sequence of transformations is defined  in order to transform the $\pi$-use case model  into other models that refine them. 
%, the $\pi$-ServiceProcess model is generated.
 
%In $\pi$SOD-M, a \textsc{Use Case} can be related with a set of
%\textsc{Constraints} (in $\pi$-UseCase model). In specifying the $\pi$-UseCase
%model, \textsc{Constraints} are always associated with a \textsc{Use Case}. 

In the $\pi$-UseCase  model 
each constraint is associated with a type of non-functional requirement
(candidate). During the transformations, this service restriction is 
refined in order to have an accurate description to describe the desired
non-functional requirement. The \textsc{Constraints} are grouped into
\textsc{Contracts}, where the \textsc{Constraints} of the same use case are
transformed into \textsc{Assertions}, and these \textsc{Assertions} compose a
\textsc{Contract} (in $\pi$-ServiceProcess model).   


The $\pi$-ServiceProcess model at the PIM level describes the business process,
and its restrictions grouped and modeled as \textsc{Contracts}.  A contract models a   non-functional property (e.g., security). At the PSM level, contracts  are grouped into a
\textsc{Policy} (in $\pi$-ServiceComposition model).  The $\pi$-ServiceComposition model is generated from the
$\pi$-ServiceProcess model.
The $\pi$-ServiceComposition 
describes which external services are related to each action/operation in the
business process. 

%From the $\pi$-ServiceComposition model it is possible to
%generate a specification for any language for describing services composition.


The main objective of having two models to describe the service process 
($\pi$-ServiceProcess and $\pi$-ServiceComposition)  is to have a clear
separation of concepts to be modeled at each stage of development. While the
($\pi$-ServiceProcess model describes the business process model without specifying the "agent" that will execute each task, the
$\pi$-ServiceComposition model describes the services needed for its implementation. Then it is possible to map the concepts of a $\pi$-ServiceComposition model  to a process language  for partially implementing   the service oriented application and combine it with NFR that expressed in a WS-* document(s).  Using $\pi$-PEWS eases the transformation since it includes expressions for implementing the application logic as a service composition and the associated policies. 

%Although WS-BPEL defines a similar set of concepts, our goal was
%also to simplify the description of these process.
 

%____________________________________________________________________________________________
\paragraph{Transformation rules}
%____________________________________________________________________________________________

define the equivalence of concepts of the meta-models of the  $\pi$SOD-M
modeling levels. We defined these transformations in a semiformal way that combines natural language and UML concepts and we implemented them using the ATL language \cite{atl_manual}:
\begin{itemize}
\item 
\textit{$\pi$-UseCase$\pi$-ServiceProcess} defines how the application and its associated requirements expressed in a $\pi$-use case with constraints are transformed into  a service
process that groups constraints of the same type and models them as {\sc Contracts}
and {\sc Actions}.

\item \textit{$\pi$-ServiceProcess$\pi$-ServiceComposition} refines the service process with contracts into a service composition that explicitly models the services that will be used for implementing {\sc Service Activities}, and transforms contracts and actions  into {\sc Policies}. 
\item  \textit{$\pi$-Service\-Composition$\pi$-PEWS} we propose two groups of rules: those that transform services composition
elements of the $\pi$-ServiceComposition into $\pi$-PEWS \textit{namespace,
alias, service} and \textit{path} elements; and those that transform
\textit{rules} grouped by \textit{policies} ($\pi$-ServiceComposition) into
\textit{A-policy} ($\pi$-PEWS) types.
\end{itemize}
In the $\pi$SOD-M environment the programmer must verify if
the transformations are valid or not. If a problem is identified, the target model can be
modified or completed. We used the Acceleo \cite{acceleo}
environment to define and run the transformation rules that produce  a \textit{.pews} file as final result. The transformations in ATL will be included as an Appendix of the thesis.  



%____________________________________________________________________________________________
\paragraph{Code generation}
%____________________________________________________________________________________________
The $\pi$SOD-M methodology uses $\pi$-PEWS as intermediate language for supporting the generation of executable code. Other meta-models and transformations can be defined for supporting  code generation into WS-BPEL, XAML and other languages adapted for
describing business/service process. 
$\pi$-PEWS is a behavioral language for defining web services interfaces by specifying
the input/output interface of a web service exported method but also
the expected behaviour of its methods (e.g., dependencies, exchanged messages). The extension  $\pi$-PEWS extension was inspired by languages like JCML \cite{CostaMMN12},
JML \cite{LeavensKP07} and Eiffel \cite{Meyer92b}, which introduce the notion of  contract for
specifying the behavior of a function. In $\pi$-PEWS this behaviour can be
specified by defining the order in which the methods of  services will be executed within a business
process and methods input/output restrictions.  




%The $\pi$SOD-M methodology proposes a model transformation for generation of
%code in $\pi$-PEWS specification. The code is produced from a \textit{$\pi$-PEWS}
%model, after it be generated by a model transformation from
%\textit{$\pi$-ServiceComposition} model.  

% Some proposals specify services and their compositions by adding
% behavioral characteristics, such as $\pi$-PEWS \cite{Placido2010LTPD}, or even
% WS-BPEL \cite{ws-bpel2}. 


 
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Evaluation}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -


The implementation of the $\pi$SOD-M environment, considering the ATL
and Acceleo transformations includes: (i) all $\pi$SOD-M meta-models, (ii)
editors for each model for the applications being developed, and (iii) the
plugins for the transformations defined by the methodology. We used the environment for evaluating our methodology by implementing example applications (named use cases in the manuscript in Chapter 5 \footnote{We will use the term
``\textbf{\textit{Examples}}'' instead of use cases and {\em evaluation} instead of   \textit{validation}.}). Each example provided a case study with different levels of difficulty for modeling non-functional requirements. We were also able to validate the hypothesis of the possibility of using an MDA approach for specifying non-functional requirement in the early phases of service oriented applications development.
We will perform a quantitative analysis for completing the final version
of the thesis' manuscript. We intend to perform an analysis of the code generated
in $\pi$-PEWS. Since the methodology generates the specification
of the application, describing the workflow and contracts, we will make a
comparison with a similar approaches like \cite{Milanovic2006}. 


%From the examples (``\textit{case studies}'') that were used to the evaluation of
%the proposed methodology, we could verify that the restrictions on services can be
%modeled from the early stages of development, not leaving it to the programming
%language, or to the programmer to resolve this type of problem.

We  noted that a MDA-based methodology provides a reasonable
structure for modeling service oriented applications in the presence of non-functional requirements. However, while MDA uses an object-oriented modeling language (\textit{i.e.},
UML) as the core technology, it does not provide
mechanisms for verifying the consistency of the models developed. 
The verification of syntactic consistency of the models is performed by
the some MDA tools, such as the \textit{Eclipse Modeling}. Assuming that meta-models are consistent   it is possible to proof by construction that a model is consistent if and only if it is an instance of the meta-model. However, this does not help to proof that a resulting service oriented application  and  its non-functional properties are sound, and whether different types of non-functional properties are conflicting. For the time being we assume that the programmer is able to specify and model sound and non conflicting non-functional properties for a given service oriented application. There
are some studies that address consistency of these models using  formal
approaches \cite{Varro04,PaigeV12}. The verification of the semantics and consistency of the models and of the
generated code is out of the scope of our work.
 However, we have identified this issue as
future work \footnote{Considering Chapter 6, we will
detail each future perspective.} (pg. 146) starting with the  formalization and the verification of the consistency of the transformation rules proposed by $\pi$SOD-M. 
 
  
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
\section{Related Works and Comparison}
\label{sec:relatedWorks}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Questions}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

\begin{quotation}\sf\footnotesize
\noindent
14 - Senti falta de cita\c c\~oes a trabalhos de John Mylopoulos, cujo livro e
artigos s\~ao os mais importantes na \'area de RNFs. Em particular, o livro
``Non-Functional Requirements in Software Engineering'' \'e uma esp\'ecie de
``bíblia'' da \'area. Al\'em desta, existe uma vasta literatura sobre RNFs n\~ao
mencionada no texto: KAOS, i-star, NFR, URN/GRL (padr\~ao da ITU-T). A quase totalidade dos
elementos presentes nos metamodelos propostos j\'a constam nos trabalhos
mencionados acima, e.g., NF-Attribute, NF-Requirement, NF-Action, NF-Properties.
Inclusive, j\'a existem tamb\'em metamodelos e UML profiles para modelagem de RNFs. 


Por fim, tamb\'em senti falta de men\c c\~ao aos padr\~oes WS-* que se
relacionam a RNFs: WS-Policy, WS-SecurityPolicy, WS-Reliability, WS-Transaction,
e ``Quality Model for Web Services''.
\end{quotation}  

\begin{quotation}\sf\footnotesize
\noindent
19 - Observe que o trabalho de D'Ambrogio [34] tamb\'em tem MDA, RNFs e servi\c cos,
ou seja, ele deveria estar na mesma \'area que a proposta da tese na Figura 3. 
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
38 - Por que as pol\'iticas n\~ao s\~ao descritas em WS-Policy? Existe tamb\'em
metamodelo deste padr\~ao? WS-Policy \'e amplamente conhecido e j\'a suportado por
diversos ambientes de execu\c c\~ao para aplica\c c\~oes orientadas a servi\c cos.   
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
40 - Por que as regras de transforma\c c\~ao n\~ao foram descritas em ATL? 
\end{quotation}

\begin{quotation}\sf\footnotesize
\noindent
34 - Observe que processos em WS-BPEL possuem muito mais do que ``sequence of
activities'' (ver frase ``It can be visualized with a flowchart as a sequence of
activities with interleaving decision points''). Na pr\'atica, por tr\'as desta
minha observa\c c\~ao est\'a a constata\c c\~ao de que o modelo para defini\c c\~ao de processos proposto ( PI-ServiceProcess) \'e muito mais simples do aqueles apresentados em
nota\c c\~oes como URN e WS-BPEL (usadas com o mesmo objetivo e que j\'a possui
metamodelos).    
\end{quotation}

% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -
\subsection{Comparing our approach with related works}
% .. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -.. - .. -

Similar to approaches such as WS-*, our work targets the specification and programming of service oriented  applications,
including its non-functional aspects (i.e., atomicity, security, performance,
persistence).   Our work
specifies \textit{policies} for modeling the non-functional requirements of a service composition in an orthogonal way,
\textit{i.e} separating the specification of non-functional requirements from
the main functionalities of the application. This is interesting because once  the policies for a
given application have been defined they can be reused and/or specialized for another application
with similar requirements.


The main goal of $\pi$SOD-M is to provide a way for supporting the development
of service-oriented  applications in the presence of non-functional
properties. The use of the WS-* standards
supposes that non-functional requirements are implemented according to the
knowledge that a programmer has of a specific application requirements, without
deriving them according to a methodology, thus leading to \textit{ad-hoc} solutions
that can be difficult to reuse. The main goal of $\pi$SOD-M is to provide a way for supporting the development
of service-oriented  applications in the presence of non-functional
properties. 

 
The ($\pi$SOD-M methodology) provides a model-driven structure that
encompasses concepts related with service-oriented development and
non-functional properties (modelled as \textsc{contracts} and
\textsc{policies}). The methodology provides a set of concepts, steps and transformations to develop service oriented applications. 

$\pi$SOD-M has an associated 
environment in the context of \textit{Eclipse Modelling}, built as a set of
plugins. The plugins are: \textit{$\pi$-UseCase, $\pi$-ServiceProcess,
$\pi$-SerciveComposition} and \textit{$\pi$-PEWS}, and the transformation
plugins. 

%The environment is implemented in the context of  Eclipse, the
%environmental requirements are the same as required by the Eclipse tool. 


Given that $\pi$SOD-M is  MDA-based, it allows the specification
of service compositions as an abstract model, which may be realized as a
concrete implementation (program). In $\pi$SOD-M, the $\pi$-PEWS specifications are executed
by an entity that coordinates the service compositions (orchestrating the
composition) of the system application. For the composition of services in
general, two paradigms guide the compositions: the
choreography\footnote{Considering choreography and orquestration, a detailed
description of the difference between them will be presented in the Backgroud chapter in the final version of the thesis' manuscript. These concepts will be described in this Chapter,
together with other important concepts, which are: MDA, Service-Oriented
Development, Compositionof Services \cite{NguyenHPCM09} and NFRs
\cite{MylopoulosBook99,UszokBJ04,Chung2009,Yu97,AmyotM02}.} and orchestration \cite{SalaunBS04}.
The orchestration is concerned with the flow of interactions between services
(business logic and execution order of services, such as a workflow). 
The orchestration requires an  engine that coordinates the composition execution. The choreography describes the order in which messages are ordered for using the methods exported by one or several services. The choreography is used for expressing the conversations that an application can have with a service. A conversation specifies the sequence of valid messages that a service con receive. These sequences correspond to the protocols for exchanging
messages with a service. 


There are other approaches for service-oriented development that do not
 use MDA. For example the methodologies  DEVISE \cite{DEVISE} and S-Cube \cite{scube2010book} for defining infrastructure Web
services.   D'Ambrogio \cite{DAmbrogio06} proposes a WSDL extension
for describing QoS in Web Services, and an MDA approach with one level of
transformation. This work proposes a WSDL extension using MDA. We
 conclude that MDA is typically used in developing service-oriented
applications \cite{AchilleosKP11,CastroMV11,DamascenoLMSSAMRSL11,KaterosKTV08,DAmbrogio06},
for generating code for a particular service description or  languages.
  

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Synthesis and discussion}
\label{sec:synthesis}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 Our work enables the modeling of non functional properties and their associated recovery actions and the way they are associated  to a service composition expressed as a workflow. In the modeling phase of our methodology, non-functional properties are seen as business rules and constraints (e.g. privacy requirements with respect to data used within the process, temporal constraints on the communication with a service) specified semi-formally. These requirements  are part  of  a business process specification (e.g., online purchase process). Along the phases of the methodology these business rules and constraints are modeled using more concrete concepts that lead  to their implementation in executable code.
 
 In general, existing approaches dealing with non-functional requirements in the distributed systems, the database and the software engineering domains, suppose a good knowledge of the programmer who is in charge of implementing and running the non-functional services according to given application requirements. Our work benefits from these previous results in order to provide a software oriented methodology that can include in the different development phases the specification of non-functional properties, their modeling and implementation. Thereby, our methodology provides meta-concepts that can be specialized for modelling different non- functional properties (security, atomicity, exceptions, persistency)  and associated  to a service composition. 

 

\bibliography{respostas,docbi}
\bibliographystyle{plain}

\end{document}
